Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / networking / terms / kermit / e / v17.1 < prev next >

Wrap

Internet Message Format | 1993-01-25 | 34.0 KB

From cmg Thu Jan 14 11:57:46 1993 Return-Path: <cmg> Received: by watsun.cc.columbia.edu (5.59/FCB/jba) id AA26555; Thu, 14 Jan 93 11:57:46 EST Date: Thu, 14 Jan 93 11:57:43 EST From: Christine M Gianone <cmg@watsun.cc.columbia.edu> To: Info-Kermit Subject: Info-Kermit Digest V17 #1 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Errors-To: Info-Kermit-Request@watsun.cc.columbia.edu Message-Id: <CMM.0.90.4.727030663.cmg@watsun.cc.columbia.edu> Info-Kermit Digest Thu, 14 Jan 1993 Volume 17 : Number 1 Today's Topics: StarGROUP Patch for MS-DOS Kermit 3.12 MS-DOS Kermit, COM3, COM4, and Internal Modems Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU or KERMIT@CUVMA.BITNET. Requests for addition to or deletion from the Info-Kermit subscriber list should be sent to LISTSERV@CUVMA.BITNET or LISTSERV@CUVMA.CC.COLUMBIA.EDU. These messages must be of the form: SUBSCRIBE I$KERMIT <your-personal-name> (To start a subscription) UNSUBSCRIBE I$KERMIT (To cancel a subscription) REGISTER I$KERMIT <your-personal-name> (To correct your name) Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The file kermit/read.me is a general guide to where things are. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. All files in these directories should be transferred in text (ASCII) mode. Binaries are in kermit/bin (use ftp in binary mode). All files on watsun have lowercase names, and case is significant. You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Tue, 12 Jan 93 11:30:00 EST >From: Christine M. Gianone <cmg@watsun.cc.columbia.edu> Subject: StarGROUP Patch for MS-DOS Kermit 3.12 Keywords: StarGROUP, MS-DOS Kermit 3.12, Patches for MS-DOS Kermit >From Joe Doupnik, author of MS-DOS Kermit: Patches 11 and 12 to cure a bug that caused AT&T StarGROUP network connections to be lost after shelling to DOS (RUN, PUSH, etc). The updated patch file is in kermit/a/mskermit.pch on watsun, MSKERMIT PCH on KERMSRV. Copy it to the same directory where you keep your MSKERMIT.INI file, and make sure there is a PATCH command at the top of your MSKERMIT.INI file. Remember, MS-DOS Kermit patch files only work with the binary KERMIT.EXE (MSVIBM.EXE) distributed by Columbia University; they will not work with versions that you have built yourself from source code, or that have been modified in any manner. ------------------------------ Date: Tue, 12 Jan 93 11:40:00 EST >From: Frank da Cruz <fdc@watsun.cc.columbia.edu> Subject: MS-DOS Kermit, COM3, COM4, and Internal Modems Keywords: MS-DOS Kermit and COM3 and COM4 Keywords: MS-DOS Kermit and Internal Modems Keywords: Modems and MS-DOS Kermit, COM3/COM4 and MS-DOS Kermit With the arrival of the new breed of low-cost high-speed internal modems have come ever-increasing numbers of queries about how to use them with MS-DOS Kermit, especially on COM3 or COM4. With the help of Joe Doupnik (author of MS-DOS Kermit) and John Klensin at MIT, we have put together what I hope will be a useful guide to this complicated topic. This text has also been added to the MSKERM.BWR file. TROUBLESHOOTING MS-DOS KERMIT SERIAL PORT AND MODEM PROBLEMS "Why can't MS-DOS Kermit find my COM3 or COM4 port?" "Why can Kermit send characters to my COM port, but not read them?" "Why doesn't Kermit work with my internal modem?" First, rule out the obvious: Is everything connected and turned on? Did you give a SET PORT command for the right device, and did you give it BEFORE any other device-related commands, such as SET SPEED and SET PARITY? Remember, port-related settings apply to the port that was selected in the most recent SET PORT command, so a proper sequence would be, for example: SET PORT COM2 ; First select the port you want to use. SET SPEED 19200 ; Then set the desired speed on the selected port, SET PARITY EVEN ; and other parameters for this port, such as parity, SET FLOW RTS/CTS ; flow control, SET LOCAL-ECHO OFF ; and CONNECT-mode echoing. Each of these parameters is remembered for each port, so switching ports (e.g. SET PORT COM1 after you have given the above sequence of commands) switches all of these parameters to their previous (or default) values for the port you have switched to. To see the current port-related parameters, type the MS-DOS Kermit command: SHOW COMMUNICATIONS This displays all the relevant information about your currently selected communication device, which is COM1 by default. Check the settings carefully to be sure they are what you intended. * * * * The following discussion, which applies to MS-DOS Kermit versions 3.11 and 3.12, is detailed and technical, but most of it boils down to (a) installing a patch; (b) telling Kermit two numbers, the port address and IRQ value; and (c) fiddling with your modem. Keep that in mind as you read more about PC hardware than you ever wanted to know. HOW A PHYSICAL COMMUNICATION PORT IS ASSOCIATED WITH A DOS COMn DEVICE DOS PCs come with full support for two communication ports, COM1 and COM2, but with provisions for at least two more, COM3 and COM4. The basic problem with COM3 and COM4 is that they are not well (or consistently) supported in most types of PCs, as are COM1 and COM2 which rarely (by themselves) cause any problems. This discussion considers only COM1-COM4, since higher-numbered COM ports are rare, and in any case are not presently supported by MS-DOS Kermit. The digit in the port name is an index into an area in memory that contains the address of the serial port hardware. The BIOS (the PC's Basic Input/Ouput System) has four words reserved starting at segment 40 (hexadecimal), word 0, to hold the addresses of the first four COM ports. Word 0 defines COM1, word 2 (two bytes per word) defines COM2, word 4 COM3, and word 6 COM4. To view these addresses: C:\> debug (start the debug program) -d 40:0 (display segment 40) -q (quit the debug program) ("C:\>" is the DOS prompt, "-" is the debug prompt.) Here are the results of this operation on a PS/2 with 3 COM ports: 0040:0000 F8 03 F8 02 20 32 00 00-BC 03 00 00 00 00 60 03 .... 2........`. 0040:0010 65 46 00 80 02 00 00 20-00 00 38 00 38 00 3E 34 eF..... ..8.8.>4 0040:0020 20 39 78 2D 2E 34 78 2D-0D 1C 64 20 20 39 34 05 9x-.4x-..d 94. 0040:0030 30 0B 3A 27 30 0B 0D 1C-75 16 67 22 20 39 00 00 0.:'0...u.g" 9.. 0040:0040 0A 00 C3 00 00 00 00 00-00 03 50 00 00 10 00 00 ..........P..... 0040:0050 00 18 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0040:0060 0E 0D 00 D4 03 29 22 76-07 35 18 FF F9 C8 0F 00 .....)"v.5...... 0040:0070 00 00 34 12 00 01 00 00-14 14 14 20 01 01 01 01 ..4........ .... The first line contains the COM port information (ignore the other lines, as well as the funny characters on the right). "F8 03" is the 2-byte COM1 address, expressed in hexadecimal (base 16) with the low byte shown first. Thus the actual COM1 address is 03F8 hex, which is expressed in Kermit commands as \x03f8. The COM2 address is 02F8, the COM3 address is 3220, and (since there is no COM4) the COM4 address is 0000. That is how both DOS and the BIOS (and hence many communication programs, including Kermit) understand which ports are defined, and where to find them. When your PC is powered up, the BIOS startup code checks for serial port hardware (that is, a Universal Asynchronous Receiver/Transmitter, or UART) at the two port addresses 03F8 and 02F8. If it finds a UART at the first address then that address is placed in word 40:0 and declared to be COM1. Then the BIOS tries the second address and if successful this address goes into the first available word at that time, typically 40:2 as the address of COM2. Thus if you remove a COM1 device then a previously COM2 device will appear in the COM1 Bios storage area and become COM1 to DOS and Kermit. What happens to the other two words depends on the PC model and BIOS. The IBM PS/2 BIOS fills in all four words on startup, but most others (there are exceptions) handle only the first two because that's how IBM did it with the original PCs. So... just setting switches or jumpers on a serial port board or internal modem does NOT define the board to be a particular COM port. Why, then, do some communication programs work with COM3 and COM4 without any special fiddling? The answer is that these programs ASSUME that COM3 and COM4 are found at certain addresses, even when there are no entries in segment 40, the BIOS communication-port area. Some of these programs show you their assumptions in a menu (and might allow you to change them), others do not. The assumed values are usually as follows: Port Assumed Address (hexadecimal) COM1 03F8 COM2 02F8 COM3 03E8 COM4 02E8 NOTE: PS/2s use different addresses for COM3 and COM4 -- 3220 and 3228, respectively, but these addresses are installed by the BIOS into segment 40 when the PS/2 is started, so well-behaved communication software (like Kermit) will use these addresses rather than the defaults listed above. Ill-behaved software will ignore the segment-40 addresses and erroneously attempt to use its own values, which, with luck, might be correct but, more likely, will not work, or at worst, can disrupt normal operation of your PC. Unchecked use of an assumed port address is DANGEROUS if the device is not really where the software expects, but the software goes ahead and uses the address anyway, in particular if some other type of device, say a network adapter, is at the given address. It can also produce unwanted conflicts under Windows, OS/2, and DesqView, whose drivers often set the port's segment-40 word to zero when they want to use the port exclusively and without interference, and then restore the real address when they are done, and similar unwanted interference with Int 14H redirectors that allow serial-port communication software to be used on network connections. Unlike most other PC communication software, Kermit will NOT attempt to use a communications port unless: (a) It finds its address in the BIOS comm-port area, segment 40, or: (b) You specify the address yourself AND: The device at the given address passes certain tests, in which registers (addresses related to the port's base address) contain certain values that are legitimate for a UART. In other words, KERMIT IS MORE CAREFUL than most other communication software, because does not want to chance disrupting normal operation of (or damaging) your PC. SPECIFYING THE PORT ADDRESS If you tell MS-DOS Kermit to SET PORT COMn (where n is 1, 2, 3, or 4), and Kermit responds: Warning, no hardware for this serial port. This port will be operated through the BIOS as BIOSn it means that Kermit did not find an address for the port in the BIOS area or it did find one but the hardware at that address did not look like an IBM-PC compatible UART. If the cause of the message is a missing address, you can tell MS-DOS Kermit the address of the port by issuing the following command: SET COMn \xhhhh where n is 1, 2, 3, or 4, and hhhh are four hexadecimal digits (0-9, A-F) representing the 16-bit address. This command not only informs Kermit of the address, but also inserts the address into the appropriate word in segment 40 so other programs can find the port (assuming they follow the rules), and so you don't have to give this command to Kermit again until after the next time you reboot. After giving the SET COMn command, give a SET PORT COMn command for the same port. The SET COMn command must come first, then the SET PORT COMn command, as in this example for COM3: set com3 \x3f8 ; Specify the address of COM3 set port com3 ; Select COM3 How do you know what addresses to give? Suppose you have purchased an internal modem or an add-on serial port and you want to install it as a particular COM port, say COM3. The installation instructions for your device will tell you how to do this. The device must be configured -- generally by setting little switches or installing or removing jumpers. The manual should tell you the address for each COM port. You have to make sure that the address that you have configured for the device agrees with the address that Kermit will use. Although it is not recommended that you guess at address values, sometimes it is the only way (as often with inherited equipment), for which occasions here is a list of the addresses commonly used for serial ports and internal modems: Port Likely Addresses (hexadecimal) COM1 03F8 COM2 02F8 COM3 03E8, 3220 COM4 02E8, 3228, 02E0 It is relatively unlikely that you will find a serial port at any address not listed above, but you might find a port at another port's expected address. The use of these addresses in SET COMn commands should be relatively harmless (provided you don't also specify an interrupt, explained later); if there is no error message, Kermit found a possibly usable port. If there is an error message, no harm should have been done. Now let's look at the other cause for the "This port will be operated through the BIOS" message, namely that an address was found in segment 40, but the device at that address does not appear to be a genuine serial port. Why would this happen? There are several possible explanations, including: 1. The device is at a different address. Check your device's configuration again, or else your SET COMn command. 2. Your device is indeed at the given address, but its registers do not contain values expected of a true PC serial port. In that case, BIOS operation is the only alternative. 3. Your device is at the given address, but there is a conflict with another device at that address or the machine's bus speed (not CPU speed) is set so high that the hardware test gave confusing results. When Kermit operates a port through the BIOS, rather than directly, it will be MUCH slower and might not work at all because the BIOS requires the CD, CTS, and DSR modem signals to be asserted by the device connected to the port (and the CD signal is normally and by default NOT asserted by a modem before it has made a connection to another modem). In that case, you will have to configure the device (e.g. modem) to assert DSR, CTS, and CD always, or wire your modem cable to fake these signals (e.g. by cross-connecting them to DTR). Assuming you have found the right address for your COM3 or COM4 port (or nonstandard address for COM1 or COM2), and you want these addresses to be set correctly for Kermit at all times, even if it doesn't read its initialization file, you can put a command like the following in your AUTOEXEC.BAT file: set kermit=com3 \x3e8; com4 \x2e8; If you want the addresses to be set correctly in the BIOS communications area, so all applications (not just Kermit), can find the ports, put a line like this in your AUTOEXEC.BAT (substituting the appropriate ports and addresses): kermit -f nul, set com3 \x3e8, set com4 \x2e8 INTERRUPTS "I can send characters to the modem, but I never see any on my screen." This common complaint (often arising from the user's observation of the modem lights and speaker), also known as "can-talk-but-not-listen syndrome", usually means that the communication device was found at the expected address, but Kermit's idea of its interrupt is wrong. What's an interrupt? To achieve high-speed communication without interfering with other applications, Kermit reads characters from a serial device using "interrupts". Whenever a character arrives at the serial device, the device sends a signal, called an interrupt, that may be "caught" by application software such as Kermit, leaving the application free to do other work in the meantime without having to constantly look at the serial port to see if any characters have arrived (an operation called "polling", which is used by some of the other communications programs). Communications programs that use polling are not sensitive to interrupts being set properly and may therefore work with improperly-configured machines where Kermit will not (unless you give it the required information), but they also tend to take over the entire computer. In contrast to polling programs, Kermit is normally waiting for input from the keyboard, and is therefore idle if you are not typing and no characters are arriving at the communication port. In multi-tasking environments such as Windows or OS/2, this allows other applications the largest possible share of the CPU while Kermit is running. When a character arrives at the port, an interrupt signals Kermit to wake up from its keyboard-wait state and read the character from the port. But Kermit needs a way of knowing which device the interrupt came from, so it will not erroneously read characters from the wrong one. The device is identified by an Interrupt Request (IRQ) number, a small integer like 3 or 4. The BIOS does not record the IRQ number used by a serial port because the BIOS uses polling rather than interrupts for serial port input and output. Thus the communications software has to know which IRQ to use. By convention from the original IBM PC, COM1 uses IRQ 4 and COM2 uses IRQ 3. There is no standard for COM3 and above, but certain conventions are normally followed: Port PS/2 Others COM3 IRQ3 IRQ4 COM4 IRQ3 IRQ3 WARNING: Certain serial port cards and internal modems allow themselves to be configured with different IRQ numbers (such as 9), even on COM1 or COM2. Check your device's installation instructions. Some types of PCs (PS/2s, for example) allow sharing of IRQ numbers, provided each application has its own interrupt service routine and each such routine is built to chain interrupts properly (i.e. pass them along to other applications if they have arrived at the wrong place). This works, for example, with Kermit on a PS/2; you can run two copies of Kermit under Microsoft Windows, one using COM2/IRQ3 and the other using COM3/IRQ3 (i.e. two ports, same IRQ), both doing input and output simultaneously with no confusion. On most types of PCs, however, IRQs can NOT be shared, and therefore each device must have a unique IRQ number. This caution applies especially when you have a serial mouse on IRQ 3 or 4. Once Kermit knows the address of a COM port, it tests to see which IRQ number, 3 or 4, the device uses. This is a safe test and does not cause any modem signaling or communication to take place. The PC architecture has a limited range of IRQ numbers available, and so (usually) there can not be a unique IRQ number for each serial port when there are more than two. This results in the common limitation that no more than two serial ports can be active at once. MS-DOS Kermit 3.12 and earlier test first for IRQ4, and then if there is no response, IRQ3. If both tests fail, a default value is used (on PS/2s, the default is IRQ4 for COM1 and IRQ3 for COM2-4; on others is it is IRQ4 for COM1 and COM3, IRQ3 for COM2 and COM4). No error message is given in this case, but "can-talk-but-not-listen syndrome" is a likely result. Some add-on communication boards or internal modems are set up to use IRQ numbers other than 3 or 4 in order to avoid conflicts with COM1 or COM2 and/or to allow more than two COM ports to be active at once. But this can be dangerous -- for example, IRQ 5 (which is sometimes used for this purpose) is also used by the hard disk controller on the PC/XT. IRQ 7 is often used by network boards. For this reason, Kermit does not automatically test any IRQ numbers other than 3 or 4, and does not use any other IRQ number by default. But it is sometimes necessary, particularly on ISA (Industry Standard Architecture) bus machines (PC/ATs and compatibles) and earlier (such as PCs and XTs) to use an IRQ other than 3 or 4, for example when when an internal modem is installed as COM3 on IRQ4, and then use of COM1 prevents COM3 from working, and vice versa. This problem can often be solved by reconfiguring the board to use an otherwise unused unique IRQ number. Ideally this would be a normally free IRQ such as 10 or 11, but unfortunately most communication boards are not configurable for IRQs higher than 7. Here is a brief, and definitely not comprehensive, guide to the low IRQ numbers (with IRQ numbers expressed in decimal): 2 Normally available, but some video boards use it to obey an obsolete standard for indicating vertical refresh. Adjust video board jumpers to not do this. On 286's and above IRQ 2 is also known as IRQ 9: same IRQ, alternate number. Windows 3.0 had difficulty with devices using IRQ 2, but Windows 3.1 is better. 3 Normally COM2 and COM4. PS/2's use IRQ 3 for all serial ports above COM1. IRQ3 is also a favorite "factory default" of many local area network (LAN) adapters. 4 Normally COM1 and informally COM3 (except on PS/2s). 5 Secondary parallel port. Parallel ports are rarely interrupt-driven (except for Novell RPRINTER users) so this wire becomes free if you unjumper the IRQ on the parallel port board. LAN adapters are frequently placed on IRQ 5. PC/XTs use IRQ 5 for the hard disk. Be careful with this one. 6 Floppy disk drives. Leave it alone! 7 Primary parallel port. Remove as described for IRQ 5. Be careful, LAN adapters are frequently placed here. 9 Alias for IRQ 2. 10 Usually free. 11 Usually free. 12 Used by the IBM bus mouse, otherwise usually free. 13 QEMM traps math coprocessor errors here, otherwise frequently free. 14 Used by hard disk on 286 and above. Leave alone! 15 Some SCSI controllers use this. Usually free. If your communication board uses an IRQ other than 3 or 4, you will experience the "can talk but not listen" syndrome when using Kermit. To force Kermit to both talk AND listen to the device, you must inform Kermit of the device's IRQ number. This is done in the SET COMn command, after the address: SET COMn <address> <irq> for example: SET COM3 \x03e8 5 When you include a number (like 3, 4, 5, 6, or 7) after the port address (separated by a space), Kermit will skip its IRQ test and use the IRQ number you have specified when you next give a SET PORT command for that port. PLEASE NOTE that you MUST AVOID address and IRQ conflicts; these items MUST NOT overlap existing equipment. SERIOUS DAMAGE can result if, for example, the IRQ number you give is the same as the one used by your disk controller or network adapter. Incorrect operation can result if the interrupt is in use by a less critical device, such as a mouse. It is necessary to specify the IRQ number in either of these two situations: 1. The communication device uses an IRQ number other than 3 or 4. 2. Kermit's IRQ test interferes with Windows or a similar environment, and therefore must be skipped. Check your PC's configuration carefully before specifying an IRQ number. Before starting Kermit, you can use certain public domain or commercial utilities, such as MAPMEM, Northgate QAPLUS, Quarterdeck MFT, or the MSD utility shipped with Windows 3.1 to get an idea of which IRQ numbers are already in use (these utilities are, of course, not foolproof -- for example, they can't tell what IRQs are used by programs that are not presently loaded). If, even after establishing the device's interrupt correctly, Kermit still fails to operate correctly (or reliably), check to see whether: 1. Some other device (such as a mouse or LAN adapter) is generating the same interrupt. 2. Some other software (such as a mouse driver) is catching the same interrupt. If you find a conflict, take whatever means are at your disposal to remove it: remove the offending device driver or TSR from your CONFIG.SYS or AUTOEXEC.BAT file, or turn it off temporarily (e.g. with the MOUSE OFF command for certain mouse drivers); or reconfigure one of the conflicting devices to use a different interrupt. PROBLEMS WITH MODEMS "I just bought and installed an XYZ V-Dot-Everything internal modem, and it works with <name-deleted> and <name-deleted> communication packages, but it doesn't work with Kermit". This has long been a common complaint about internal modems. The same complaint is also now being heard with alarming frequency about some of the newer external modems. With internal modems, particularly when they are installed on COM3 or COM4, the most common problems are: 1. Kermit does not know the modem's address, or the device is using an IRQ number other than 3 or 4. These problems can be fixed by giving the appropriate SET COMn command to Kermit. 2. The internal modem is installed incorrectly, with an address or IRQ that conflicts with one already in use on your PC. 3. The internal modem does not correctly emulate a real IBM PC serial port, and therefore fails Kermit's hardware test, and therefore can only be used through the BIOS. 4. The device is in a laptop, notebook, or palmtop computer, and power to the internal modem or serial port has been disabled in the CMOS setup, or has been turned off automatically when the cover is closed or the machine shut down. In recent months (beginning about mid-1992) a new generation of low-cost, high-speed modems, both internal and external, began to appear on the market. These modems typically offer a wide range of features: V.32 and V.32bis modulation, V.42 and MNP error correction, V.42bis and MNP data compression, etc. Unfortunately, many of these modems suffer from bugs not found in earlier (and usually more expensive) modems. The problems are generally related to initialization of the modem and interaction with its command processor. Some common complaints: 1. An internal modem does not work at all; the modem becomes nonoperational as soon as Kermit attempts to access it. The cause has been traced to the fact that Kermit's initialization of the modem's UART is "too fast" for some of these new modems. (This same initialization sequence has been used for nearly a decade with no problems, and still works on the well-known and reputable brands of internal modems.) 2. "Kermit won't dial or respond to modem commands". The modem ignores dialing or other commands from Kermit. Or the modem ignores commands when Kermit's PARITY is set to a particular value, like EVEN. Or commands are not processed correctly above a certain interface speed. 3. "I can dial successfully, and in general send characters to and through the modem, but I never get any characters back." This looks suspiciously like the "talk-but-not-listen" problem, but in some cases it is a bug in, or a configuration problem with, the modem, having nothing to do with Kermit: the modem is simply not sending any characters to the PC. 4. "After using the modem with <name-omitted> communication software, it also works with Kermit, but it won't work with Kermit unless I run <name-omitted> first." And so on. All of these are modem, not Kermit, problems. Here are some suggestions for overcoming them: 1. Slow the UART-initialization sequence. This is accomplished by patch #11 to MS-DOS Kermit 3.11 and patch #10 to version 3.12. These patches have been tested successfully on several of the misbehaving modems. Get the patch file for your version of Kermit (3.11 or 3.12). The patch files are in kermit/a/msr311.pch and kermit/a/msr312.pch on watsun.cc.columbia.edu on the Internet, available via anonymous FTP. Rename the file to MSKERMIT.PCH and put in the same directory as your MSKERMIT.INI file, and start Kermit again. At the MS-Kermit> prompt, give a VERSION command to make sure the patches were installed. If not, give a PATCH command (or, better still, make sure that PATCH is the first command in your MSKERMIT.INI file, and that your MSKERMIT.INI file is in your DOS PATH so Kermit will always execute it). 2. External modems only: Check that your modem cable has wires for (at least) the TD, RD, SG, CTS, RTS, DSR, CD, and DTR RS-232 signals. If it does not, replace the cable with a real modem cable, or (temporarily) configure your modem to compensate for the missing signals. 3. Read your modem manual and check your modem's configuration. Perhaps its interface speed is locked to a different speed than the one Kermit is using. Perhaps it is set to use hardware flow control, but Kermit is not. Also, check its factory and/or saved settings, and under what conditions they are restored (for example, are they restored when the PC drops DTR?). How are you selecting saved settings -- read your modem manual about (for example) the difference between AT&F and AT&F2. Be aware that the AT&Fn commands might not restore all S-registers, so double check them. Be particularly sensitive to the registers that control interface speed, modulation technique, error correction, data compression, negotiation, and fallback, and note that each modem maker probably uses different registers and commands to control each of these features. 4. Try the following sequence to initialize the port (using COM3 in this example): SET COM3 <address> <irq> ; (if necessary) SET PORT 3 ; Select port 3 HANGUP ; Drop DTR on port 3 SET PORT 3 ; Re-initialize port 3 5. SET PARITY NONE when talking to the modem, and then set parity to whatever the remote host or service requires after making the connection. (WARNING: MS-DOS Kermit might set its parity to some other value automatically as a result of automatic parity detection during file transfer.) 6. Ensure that your PC bus speed is 8MHz. Some PCs (not PS/2s) come with a BIOS SETUP facility that lets you change the PC's bus speed, memory wait states, etc. In general, it is dangerous to deviate from the defaults, particularly from the 8MHz bus speed, which is a standard for add-on devices, and might be required by your communication board or internal modem. 7. Modify HAYES.SCR, or whatever dialing script you are using, to take extraordinary measures to ensure the modem is in command mode, and to send its initialization commands very slowly and to try them repeatedly. For example, change "output ATQ0V1X1\13" to something like this (note: the modem-related commands shown here are all relatively portable -- you might also need additional modem-specific commands, such as AT&F2 to load a particular configuration, or specific S-register settings affecting speed, flow control, modulation, fallback, etc.): WAIT 1 DSR ; See if modem is asserting Data Set Ready IF FAIL FATAL - {No DSR signal: Is your modem connected and turned on\63} SET PARITY NONE ; Use no parity SET COUNT 5 ; Try 5 times to initialize :INIT HANGUP ; Modem is connected - hang up on it. CLEAR ; Clear Kermit's input buffer. OUTPUT \B ; Send a BREAK. PAUSE ; Wait a second. OUTPUT \17 ; Send a Ctrl-Q in case modem is Xoff'd. PAUSE 2 ; Wait two seconds. OUTPUT + ; Send the most likely escape sequence, OUTPUT + ; which is "+++" with at least a second of OUTPUT + ; "silence" before and after. PAUSE 2 ; ... OUTPUT \13 ; Send a carriage return. PAUSE ; Wait a second. OUTPUT A ; Send an A. PAUSE ; Wait another second. OUTPUT T ; Send a T. PAUSE ; Wait another second. OUTPUT \13 ; Send a carriage return. PAUSE ; Wait a second. CLEAR ; Clear away echo and response. OUTPUT A ; Send initialization command. OUTPUT T ; One character at a time... PAUSE OUTPUT Q ; Q0 = Result codes enabled OUTPUT 0 OUTPUT V ; V1 = Word result codes OUTPUT 1 OUTPUT X ; X1 = Dial response level OUTPUT 1 OUTPUT \13 ; Carriage return terminates the command PAUSE INPUT 3 OK ; Wait for OK response. IF SUCCESS GOTO INITOK ; Got one. IF COUNT GOTO INIT ; Didn't, try again. ECHO Failure to initialize modem. ; No more tries. STOP 1 ; Fail. :INITOK If this doesn't work, insert a PAUSE command after each OUTPUT command or run the script at a lower speed. 8. Dial at a lower speed. Make your interface speed match the modulation speed -- e.g. use 9600 for V.32, 2400 for V.22bis, etc. Turn off fancy modem options like error correction and compression. etc etc. NOTE: connection problems between the two modems have nothing to do with Kermit and are beyond the scope of this document. If a modem appears to dial correctly, gets connection tones, and then hangs up, it is undoubtedly a problem between the two modems (involving one modem, both modems, and/or the phone company), and indicates a modem configuration problem, a bug, or a basic incompatibility between the calling and answering modems. 9. Call your modem maker's technical support number. Ask if they have replacement chips to fix bugs in your modem. ------------------------------ End of Info-Kermit Digest *************************